Cloud computing provides users (also referred to as “tenants”) with services, such as software as a service (SaaS), platform as a service (PaaS), and infrastructure as a service (IaaS), that are hosted in distributed computing environments (i.e., a cloud). Tenants may deploy their applications in various traditional data centers or in cloud networks, including, but not limited to: on-premises private clouds, hosted private clouds, service provider clouds, and public clouds. Tenants may also deploy their applications across multiple clouds for various reasons, including, but not limited to: reducing the risk of downtime, as an emergency backup, or part of a planned transfer from one cloud to another (e.g., for performance gains or cost savings).
When a given application or machine is originally deployed in a given network, it often needs to be reconfigured when moved to a new network so that communications with the application or machine continue to function properly or the infrastructure on which it is deployed (including infrastructure-linked systems and applications) needs to be reconfigured. For example, a user may wish to leverage the network of a cloud service provider, and deploy or move the virtual machines providing the applications to the chosen cloud network from an existing network. The step of reconfiguring the applications or infrastructure to function with the new cloud network requires computing resources to be expended, and can result in the application being unavailable for a changeover period while users and linked systems learn of the new location of the application.
There are multiple methods in which an application or infrastructure is reconfigured to enable communication with remotely linked systems in the network, including: creating separate networks/subnets in an existing local network or cloud, or in a new local network or cloud; and stretching an existing subnet across new and existing local networks and clouds. Currently, users who employ technologies to “stretch” their subnet across multiple distributed computing environments will typically use a layer-2 (L2) gateway, or change the subnet mask and use a layer-3 (L3) hub for all communications, or will reconfigure the applications to account for the different locations to which the subnet is stretched. As will be appreciated, L2 communications require greater overhead than L3 communications, which can cause issues (including latency and broadcast storms) with respect to how communications are handled, and, as a result, not all clouds use L2 communications. As will also be appreciated, L3 hubs (with subnet mask of /32) increase the number of steps a communication must pass through, as a central handler must process the communications and may introduce errors into the communications, and require that IP settings (e.g., subnet mask, default router configuration) be reconfigured in the network infrastructure and/or the machines running on the network.